What can air combat teach us about software project failure?

Colonel John Boyd invents the concept of the OODA

In the 1950s, John Boyd revolutionized aerial combat. People call him “40 Second Boyd”. They called him that because he had a standing bet. His offer was that he and an opponent could start from any position in the air. He would defeat the person in 40 seconds or less. He never lost his bet.

He was influential in a many ways, but one of the things he’s known for is his theory of how to win in aerial combat. The secret is not to have the fastest plane. The key to victory is to create situations where you can make good decisions more quickly than your opponent. He called this idea the OODA loop. The idea was to

• Observe,
• Orient,
• Decide, and
• Act

…faster than anybody else. He said, “Time is the dominant parameter. The pilot who goes through the OODA cycle in the shortest time prevails because his opponent is caught responding to situations that have already changed.”

Focusing on speed in engineering teams is a mistake

War metaphors only go so far. But this is relevant to engineering and business. The speed we iterate is more important than how fast we are going. Too often, we focus on team output, or whether a project is on time. It’s far more important that the team observe, orient, decide and act quickly and effectively.

If you’re able to do something small and learn from it, and do that over and over again, you’ll usually come up with something far better than something big with less feedback.

If you make a mistake with small increments, you’ll have lots of chances to correct yourself. With the big monolithic approach, you only have once chance to get it right. [Narrator: you won’t get it right].

Fast feedback loops + good sensing == great outcomes

So, we need to focus on things that speed our feedback loops:

• Keep scope small.
• Decide things quickly. Don’t overthink decisions that are reversible.
• Coordinate effectively.
• Build trust with each other, so we can act quickly.
• Orient and provide excellent context.

We can do this in our individual actions, as individual contributors, and as managers. And most importantly for engineering, we must do this in our projects, because it enriches the value of engineering organizations immensely to deliver things in faster, smaller loops.

One of the most common failures I see in engineering organizations is shipping big projects. In these projects, you learn the result of your project at the end. You often miss the mark. Focusing on projects as the unit of delivery is flawed. Instead, break things into pieces, and focus on validation and learning as often as you can during the course of the project. The results will be far superior.

Part of the reason this is so valuable is that velocity is a vector: it combines movement with a direction. Incremental delivery helps ensure your direction fits your customer needs, so even if it were less efficient to be incremental, the results are almost always better.

Thank you

Thanks to Alex Kroman for this post. He wrote a similar blog post a long time ago that disappeared from the internet. When I attempted to find it, he said it was gone. So, I wrote it from memory. Then I remembered archive.org, and as I was writing up this thank you found his original post!

Thank you to Andrea for pointing out a typo.

Images are courtesy of Wikipedia.